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ABSTRACT 

Although  meant  to  be  relatively  stable,  the  architecture  of  a  software  system  does,  at 
times,  change.  This  simple  yet  important  observation  immediately  raises  the  question 
of  how  changes  to  an  architecture  should  be  captured.  Current  architecture  description 
languages  are  not  well-suited  for  this  purpose,  but  existing  techniques  from  the  discipline 
of  configuration  management  can  be  adapted  to  provide  a  solution.  In  particular,  we 
propose  a  novel  representation,  called  configurable  software  architecture,  that  extends 
the  traditional  notion  of  software  architecture  with  the  concepts  of  variants,  options, 
and  evolution.  We  discuss  the  details  of  the  representation,  present  an  environment 
that  allows  the  specification  of  configurable  software  architectures,  and  highlight  a  few  of 
the  opportunities  that  we  believe  arise  once  architectural  configurability  can  be  precisely 
captured. 


This  work  was  supported  in  part  by  the  Air  Force  Materiel  Command,  Rome  Laboratory,  and  the  Defense  Advanced 
Research  Projects  Agency  under  Contract  Numbers  F30602-94-C-0253  and  F30602-98- 2-0163.  The  content  of  the 
information  does  not  necessarily  reflect  the  position  or  the  policy  of  the  Government  and  no  official  endorsement 
should  be  inferred. 


Report  Documentation  Page 

Form  Approved 

OMB  No.  0704-0188 

Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 

VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 

1.  REPORT  DATE 

DEC  1999 

2.  REPORT  TYPE 

3.  DATES  COVERED 

00-00-1999  to  00-00-1999 

4.  TITLE  AND  SUBTITLE 

Capturing  Architectural  Configurability:  Variants,  Options,  and 

Evolution 

5a.  CONTRACT  NUMBER 

5b.  GRANT  NUMBER 

5c.  PROGRAM  ELEMENT  NUMBER 

6.  AUTHOR(S) 

5d.  PROIECT  NUMBER 

5e.  TASK  NUMBER 

5f.  WORK  UNIT  NUMBER 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Department  of  Computer  Science, University  of 

Colorado, Boulder, CO, 80309 

8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

10.  SPONSOR/MONITOR'S  ACRONYM(S) 

11.  SPONSOR/MONITOR'S  REPORT 
NUMBER(S) 

12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 

13.  SUPPLEMENTARY  NOTES 

The  original  document  contains  color  images. 

14.  ABSTRACT 

see  report 

15.  SUBIECT  TERMS 

16.  SECURITY  CLASSIFICATION  OF: 

17.  LIMITATION  OF 

ABSTRACT 

18.  NUMBER 

OF  PAGES 

20 

19a.  NAME  OF 

RESPONSIBLE  PERSON 

a.  REPORT 

unclassified 

b.  ABSTRACT 

unclassified 

c.  THIS  PAGE 

unclassified 

Standard  Form  298  (Rev.  8-98) 

Prescribed  by  ANSI  Std  Z39-18 


1  Introduction 


Rarely  a  software  system  has  been  constructed  that,  once  delivered  and  in  use,  was  never 
modified.  In  fact,  it  is  well-known  that  most  successful  software  systems  undergo  a  large  number 
of  changes  over  time.  Managing  all  these  changes  has  almost  exclusively  been  the  domain  of  the 
discipline  of  configuration  management  for  quite  some  time  now.  In  particular,  advanced  techniques 
have  been  developed  to  address  (among  others)  the  following  two  problems:  capturing  the  ever 
constant  state  of  flux  that  the  source  code  of  a  software  system  appears  to  be  in,  and  selecting  a 
particular  system  configuration  out  of  the — potentially  very  large — set  of  available  source  code.  In 
essence,  these  techniques  can  be  characterized  as  managing  the  configurability  of  a  software  system. 

The  mere  existence  of  configurability  can  basically  be  attributed  to  three  phenomena,  namely 
variability,  optionality,  and  evolution.  Although  these  three  phenomena  are  closely  related,  it 
should  be  understood  that  they  represent  three  very  distinct  concepts.  Variability  refers  to  the 
fact  that  a  single  software  system  can  provide  multiple,  alternative  ways  of  achieving  the  same 
functionality.  As  an  example,  consider  a  numerical  optimization  system  [6]  that  has  been  engineered 
to  operate  either  slow  but  very  precise,  or  fast  but  only  approximate.  Depending  on  the  desired 
mode  of  operation,  the  selection  of  source  files  included  in  the  actual  system  configuration  can  be 
very  different.  Optionality  means  that  a  software  system  has  one  or  more  additional  parts  that 
each  may  or  may  not  be  incorporated  in  the  system.  For  example,  consider  the  fact  that  the 
numerical  system  can  optionally  gather  statistics.  The  source  files  that  implement  the  gathering 
and  analyzing  of  the  statistics  at  run-time  are  only  included  in  the  system  configuration  if  the 
option  to  gather  statistics  is  turned  on.  Finally,  the  term  evolution  is  used  to  capture  the  notion 
that  a  software  system  changes  over  time  to  provide  a  related  yet  different  set  of  capabilities.  Once 
again,  the  numerical  system  provides  an  example  in  that  it  evolved  from  initially  being  capable 
of  only  optimizing  rather  simple  functions  to  now  optimizing  large  and  very  complex  functions. 
Obviously,  the  system  configuration  has  changed  over  time  as  the  capabilities  of  the  system  have 
increased. 

With  the  emergence  of  the  discipline  of  software  architecture,  a  new  challenge  has  arrived  with 
respect  to  managing  configurability.  It  has  been  proposed  to  use  the  architecture  of  a  software 
system  to  support  various  activities  in  the  software  life  cycle.  In  fact,  some  infrastructure  has 
already  been  developed  to  support  this  vision.  In  particular,  a  source  code  editor  that  is  explicitly 
based  on  architecture  [5],  a  tool  specifically  designed  to  test  architectures  [30],  and  a  number  of 
architecture-based  activation  systems  [17,  22]  have  been  constructed.  With  this  kind  of  use  of 
architectures,  though,  the  architectural  structure  of  a  software  system  becomes  as  important  as 
its  source  code;  both  are  delivered  and  deployed.  Moreover,  both  exist  in  multiple  variants,  both 
exhibit  optionality,  and  both  evolve  over  time.  Therefore,  the  need  arises  to  manage  configura¬ 
bility  in  architectures  analogous  to  the  way  configurability  in  source  code  is  being  managed  [36]. 
Herein  lies  the  aforementioned  challenge:  to  investigate  and  develop  techniques  that  are  capable  of 
managing  and  supporting  configurability  at  the  architectural  level.  A  key  observation  to  be  made 
is  that  this  challenge  requires  the  management  of  the  configurability  of  architectures  themselves, 
not  of  the  documents  that  describe  the  architecture.  In  fact,  it  is  not  sufficient  to  simply  version 
an  architectural  description.  Instead,  to  support  some  of  the  activities  listed  above,  configurability 
has  to  be  modeled  inside  an  architecture  itself. 

Some  aspects  of  architectural  configurability  are  starting  to  be  addressed.  For  example,  changes 
at  the  architectural  level  have  been  used  to  dynamically  reconfigure  a  software  system  at  run 
time  [13,  22],  As  another  example,  it  has  been  recognized  that  the  differences  between  architectural 
configurations  can  be  used  as  a  basis  for  regression  testing  [25].  However,  two  problems  persist  in 
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the  work  carried  out  so  far. 


•  Although  certainly  as  important  as  evolution,  neither  variability  nor  optionality  is  supported. 

•  A  suitable  representation  that  captures  architectural  configurations  and  relates  them  to  each 
other  is  lacking. 

This  paper  proposes  a  solution  for  these  two  problems  by  leveraging  the  modeling  capabilities  that 
have  been  developed  in  the  field  of  configuration  management.  In  particular,  we  propose  a  novel 
representation,  called  configurable  software  architecture ,  that  integrates  the  traditional  notion  of 
software  architecture  with  the  concepts  of  variants,  options,  and  evolution.  Although  this  work  is 
preliminary  and  we  have  not  yet  tested  the  use  of  the  representation,  we  believe  that  the  definition 
of  the  representation  is  a  first  step  towards  the  structured  use  of  architecture-level  configurability 
in  support  of  various  software  life  cycle  activities. 

The  remainder  of  this  paper  is  organized  as  follows.  We  first,  in  Section  2,  discuss  a  number  of 
myths  with  respect  to  architectural  configurability  that  need  to  be  addressed  before  we  introduce 
our  representation  in  Section  3.  We  then  discuss,  in  Section  4,  an  environment  that  we  have  created 
to  support  the  specification  of  configurable  software  architectures.  Subsequently,  in  Section  5,  we 
present  some  of  the  potential  uses  of  our  representation.  We  discuss  related  work  in  Section  6  and 
conclude  in  Section  7  with  a  summary  of  our  contributions  and  an  outlook  at  future  work. 

2  Myths 

Before  we  discuss  our  representation  for  configurable  software  architecture,  we  need  to  discuss 
a  number  of  myths  with  respect  to  architectural  configurability.  Below,  we  introduce  these  myths 
and  present  a  short  rebuttal  for  each  one. 

Architectures  do  not  change.  The  architecture  of  a  software  system  is  indeed  meant  to  be 
relatively  stable.  However,  during  the  life  of  a  software  system  it  is  likely  that  changes  occur 
that  do  have  an  impact  on  its  architecture.  Perhaps  the  most  convincing  argument  is  provided 
by  Perry  and  Stieg,  who  showed  that  approximately  50  percent  of  all  system  changes  are  interface 
changes  [23].  Given  that  a  typical  architectural  description  captures  interfaces,  we  can,  thus,  expect 
an  architecture  to  change. 

Architectural  configurability  can  be  expressed  in  existing  architecture  description  lan¬ 
guages.  It  is  certainly  possible  to  capture  aspects  of  configurability  in  some  existing  architecture 
description  languages  (ADLs).  In  fact,  certain  ADLs,  such  as  Rapide  [15]  or  Darwin  [16],  are 
even  powerful  enough  to  explicitly  program  configurability.  However,  ADLs  lack  specific  constructs 
for  this  purpose.  In  the  face  of  a  large  number  of  variants,  options,  and  evolutionary  changes, 
this  quickly  leads  to  a  complicated  and  chaotic  architectural  description  that  is  rather  difficult  to 
understand. 

Managing  architectural  configurability  is  simply  applying  a  configuration  management 
system  to  an  architectural  description.  At  first  sight,  the  use  of  a  configuration  management 
tool  (e.g.,  ClearCase  [3],  CVS  [4],  or  Continuus  [7])  to  store  and  version  architectural  descriptions 
is  an  attractive  and  simple  solution  to  capturing  architectural  configurability.  However,  if  a  config¬ 
uration  management  system  were  to  be  used,  the  configurability  aspects  of  an  architecture  would 
be  stored  as  metadata  separate  from  the  architecture.  Because  the  data  is  not  an  integral  part  of 
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the  architecture,  such  a  solution  prohibits  the  use  of  configuration  data  by  the  architecture  itself. 
In  particular,  this  becomes  a  problem  in  the  case  of  dynamic,  self-adaptive  architectures,  because 
these  need  the  configuration  data  to  govern  the  changes  they  undergo.  Moreover,  the  creation 
of  multi-version  architectures,  such  as,  for  example,  those  required  in  Hercules  [8]  or  the  Simplex 
method  [27],  is  not  supported  by  this  type  of  solution. 

Managing  architectural  configurability  is  simply  adding  a  version  number  to  the  en¬ 
tities  in  an  architectural  description.  Adding  version  numbers  to  architectural  entities  is 
certainly  a  step  towards  capturing  architectural  configurability.  However,  a  complete  solution  is 
more  complicated.  A  version  number  is  simply  an  identification  mechanism  that  leaves  the  seman¬ 
tics  of  versioning  (and  versioning  relationships)  implicit.  The  traditional  version  tree  is  one  way  of 
capturing  some  of  these  semantics,  but  architecture  has  its  own  peculiarities  that  require  the  use  of 
a  different  mechanism.  Optionality,  for  example,  is  not  supported  by  the  version  tree.  In  addition, 
the  variant  relationship  needs  to  be  extended  because,  in  an  architecture,  independently  developed 
components  can  be  variants  of  each  other.  Thus,  we  require  a  more  advanced  solution  than  just  a 
simple  addition  of  a  version  number. 

3  Configurable  Software  Architecture 

As  the  name  “configurable  software  architecture”  already  indicates,  our  representation  for  cap¬ 
turing  architectural  configurability  is  based  on  a  number  of  concepts  adopted  from  the  discipline 
of  configuration  management.  However,  as  discussed  in  the  previous  section,  a  straight  adoption  is 
not  necessarily  our  best  option;  the  unique  aspects  of  software  architecture  as  compared  to  source 
code  require  us  to  apply  some  of  the  traditional  configuration  management  techniques  in  a  rather 
different  way.  In  this  section,  we  discuss  these  aspects  and  their  influences  on  the  design  of  our 
representation  for  configurable  software  architecture.  Before  we  do  so,  however,  we  first  introduce 
a  number  of  general  principles  that  guided  the  design  and  then  introduce  an  example  system  that 
we  use  throughout  the  remainder  of  the  discussion. 

3.1  Design  Principles 

Our  representation  for  configurable  software  architecture  has  been  influenced  by  a  number  of 
design  principles.  In  the  following,  we  enumerate  these  principles  and  discuss  their  impact  on  the 
representation. 

•  Completeness.  Our  representation  needs  to  be  able  to  capture  all  types  of  configurability  to  all 
architectural  elements.  Although  a  trivial  observation,  it  influences  our  design  considerably. 
In  particular,  it  has  been  observed  that  the  need  to  create  a  representation  that  involves 
hierarchies  (an  integral  part  of  architectural  specifications),  variants,  and  evolution  already 
brings  forth  a  rather  complicated  design  problem  that  is  multi-dimensional  in  nature  [33]. 
The  addition  of  options  further  complicates  this  problem. 

•  Simplicity.  Because  we  need  to  capture  a  large  number  of  concepts  in  a  single  representation, 
a  focus  on  the  essential  aspects  to  be  modeled  is  an  absolute  necessity.  If  too  many  concepts 
are  addressed  via  advanced  modeling  techniques,  the  representation  becomes  too  complicated 
to  use.  In  that  case,  it  is  likely  that  only  a  subset  is  used  and  that  the  full  power  of  the 
representation  is  not  taken  advantage  of. 
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•  Orthogonality.  The  discipline  of  configuration  management  has  traditionally  addressed  a 
number  of  different  concepts  through  a  single  formalism:  the  version  tree.  In  [10]  it  is  argued 
that  this  is  not  a  proper  approach;  instead,  each  concept  should  be  handled  in  a  separate 
manner.  In  the  design  of  our  representation  for  configurable  software  architecture  we  follow 
this  advice  and  treat  every  concept  orthogonally. 

•  Language  independence.  A  large  variety  of  architecture  description  languages  exists  [21]. 
We,  obviously,  would  not  like  to  tie  our  representation  to  a  single  language.  Instead,  our 
representation  should  make  it  possible  to  capture  configurability  for  a  multitude  of  ADLs.  As 
demonstrated  by  Acme  [1 1] ,  this  requires  a  careful  design  that  reckons  with  the  peculiarities 
of  the  various  ADLs. 

3.2  Example 

Figure  1  presents  a  simplified  version  of  an  existing  system  that  is  currently  in  use  to  carry  out 
research  in  the  field  of  numerical  analysis  [6] .  The  purpose  of  the  system  is  to  globally  optimize  a 
mathematical  function,  i.e.,  to  find  the  point  in  the  domain  of  the  function  that  yields  the  absolute 
lowest  function  value.  The  system  consists  of  about  15,000  lines  of  Fortran  and  C  code,  and  is 
modularized  into  a  set  of  components.  In  the  figure,  each  solid  box  represents  such  a  component 
and  each  solid  line  indicates  the  existence  of  interaction  between  two  components.  For  example, 
each  Optimizer  component  interacts  with  a  single  ComplexFunction  component.  The  dashed 
lines  indicate  a  different  kind  of  relationship  among  components,  instantiation.  As  illustrated  by 
the  dashed  boxes,  the  Scheduler  component  instantiates  new  Optimizer  and  ComplexFunction 
components  in  pairs. 

In  the  system,  the  GlobalOptimization  component  manages  the  computation  that  takes  place. 
It  uses  the  Scheduler  to  create  new  Optimizer  and  ComplexFunction  components,  and  allocates 
a  particular  interval  of  the  domain  to  each  Optimizer  component.  The  Optimizer  component 
carries  out  an  optimization  algorithm  on  the  interval  that  it  has  been  allocated,  and  uses  its 
ComplexFunction  component  to  evaluate  the  function  at  the  particular  points  that  the  algorithm 
requires.  The  net  effect  is  that  the  function  is  optimized  by  optimizing  multiple  intervals  in  parallel. 

Throughout  its  lifetime,  the  system  has  been  highly  variable.  Initially,  the  ComplexFunction 
component  consisted  of  about  3,000  lines  of  Fortran  code  that  were  created  at  the  local  site,  but 
it  has  since  been  replaced  with  a  separate  system,  CHARMM,  that  was  created  at  an  external 
site.  Also,  alternative  Optimization  components  exist  that  each  exhibit  unique  characteristics 
with  respect  to  the  encapsulated  optimization  algorithm;  some  are  fast  but  produce  less  precise 
results,  whereas  others  are  slow  but  very  accurate.  Moreover,  the  system  is  configurable  to  option¬ 
ally  generate  statistics  about  its  performance.  Finally,  new  versions  of  the  GlobalOptimization 
component  are  created  on  a  regular  basis  as  new  approaches  are  being  tried  to  find  better  results. 

3.3  Basic  Architectural  Skeleton 

Figure  2  shows  the  basic  architectural  skeleton  upon  which  we  have  constructed  our  repre¬ 
sentation  for  configurable  software  architecture.  Although  syntactically  different,  the  skeleton  is 
largely  patterned  after  the  semantics  that  were  introduced  by  Acme  [11]  and  Darwin  [16].  It  con¬ 
tains  the  common  architectural  concepts  of  interfaces,  components,  and  connections.  Although  the 
skeleton  is  similar  to  some  of  the  system  models  provided  in  traditional  configuration  management 
systems  (e.g.,  Adele  [9],  DSEE  [14],  and  Jasmine  [19]),  some  important  differences  exist.  Since 
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Figure  1:  Example  System. 


these  differences  have  been  further  elaborated  upon  in  the  existing  software  architecture  litera¬ 
ture  [12,  24,  29,  34],  we  only  briefly  mention  the  core  differences  here:  besides  components  and 
their  interfaces,  connections  are  explicitly  modeled  as  well;  the  behavior  and  constraints  of  compo¬ 
nents  and  connections  are  explicitly  modeled;  both  components  and  connections  can  have  multiple 
interfaces;  and  interfaces  are  directed. 

Before  we  move  on  to  our  discussion  on  configurability,  several  words  are  in  place  about  the 
skeleton  representation.  First,  we  note  that  the  representation  is  based  on  a  type-instance  mech¬ 
anism.  However,  because  instances  define  additional  fields  besides  the  ones  defined  in  their  types, 
they  also  exhibit  an  inheritance  relationship  with  respect  to  their  types.  Thus,  our  representation 
does  not  reflect  a  type-instance  system  in  the  truest  sense  of  the  word.  To  indicate  this  difference, 
we  use  the  term  exemplar  as  opposed  to  the  term  type. 

The  second  observation  we  need  to  make  is  that,  because  of  language  independence  reasons, 
connections  are  not  required  to  have  interfaces.  Some  ADLs  have  what  can  be  considered  anony¬ 
mous  connections  whose  sole  purpose  is  to  connect  components  via  component  interfaces  (consider 
the  buses  used  in  C2  [31]  or  the  use  of  the  bind  statement  in  Darwin  [16]).  Other  ADLs  raise 
the  level  of  connections  to  what  are  called  connectors  [2,  28].  In  those  ADLs,  a  connector  has  its 
own  interfaces  and  connects  components  by  binding  the  interfaces  of  the  components  to  its  own 
interfaces.  To  support  both  kinds  of  ADLs,  the  use  of  interfaces  in  connections  is  optional  in  our 
representation. 

Two  additional  observations  need  to  be  made  about  the  skeleton  representation.  The  first  is  that 
the  hierarchical  composition  of  architectures  is  supported  through  the  construction  of  exemplars 
out  of  instances  of  other  exemplars.  That  is,  an  exemplar  is  defined  as  a  set  of  interfaces  that 
it  exposes,  a  set  of  components  that  it  consists  of,  and  a  set  of  connections  that  (internally) 
connect  the  contained  components  and  the  exposed  interfaces.  The  second  observation  to  be  made 
is  that,  even  though  connection  exemplars  are  semantically  different  from  component  exemplars, 
they  are  syntactically  identical.  This  follows  the  traditional  notion  that  connections  are  nothing 
but  components,  but  need  to  be  recognized  as  separate  entities. 

To  illustrate  the  basic  skeleton,  Figure  3  shows  a  partial  specification  of  the  global  optimization 
system.  We  first  notice  the  exemplar  Point,  which  defines  an  interface  exemplar  that  represents  a 
geographical  location.  As  described  previously,  the  representation  of  an  exemplar  is  ADL-specific. 
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{component}* 

{connection}* 

behavior 

constraints 

representation 

Connection  Exemplar 

componentExemplar 

Interface  Exemplar 

name 

representation 

Component 

Connection 

name 

componentExemplar 

name 

{ sourcelnterface  [,  myDestinationlnterface] }  * 

{ [mySourcelnterface,]  destinationlnterface }  * 
connectionExemplar 

Interface 

name 

direction 

interfaceExemplar 

Figure  2:  Basic  Software  Architecture  Representation. 

In  this  particular  case,  we  have  chosen  Darwin  as  the  language  to  use.  An  instance  of  the  exemplar 
Point  is  given  by  the  interface  result,  which  is  an  in  interface,  indicating  it  consumes  a  result 
that  is  produced  by  some  other  component. 

Hierarchical  composition  is  demonstrated  by  the  component  exemplar  GlobalOptimization. 
It  contains  the  interface  result,  as  well  as  two  components,  opt  and  eval,  and  two  connections, 
busl  and  pipel.  For  brevity,  we  do  not  show  the  definitions  of  these  components  and  connections, 
but  only  note  that  they  are  defined  in  terms  of  other  exemplars.  The  only  instance  we  do  describe, 
though,  is  busl.  This  connection  illustrates  how  the  instances  contained  by  an  exemplar  can  be 
connected.  In  this  particular  case,  the  connection  connects  the  interface  result  of  the  exemplar 
GlobalOptimization  to  the  interface  minimum  of  the  component  opt.  The  behavior,  constraints, 
and  representation  of  the  exemplar  GlobalOptimization  are,  once  again,  language  dependent  and 
not  further  defined  here. 
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InterfaceExemplar 
name  =  Point; 
representation  =  { 
integer  x; 

} 

ComponentExemplar 

name  =  GlobalOptimization; 
interfaces  =  result; 
components  =  opt,  eval; 
connections  =  busl,  pipel; 


Interface 

name  =  result; 
direction  =  in; 
interfaceExemplar  =  Point; 

Connection 
name  =  busl; 

sourcelnterfaces  =  minimum; 
destinationlnterfaces  =  result; 
connectionExemplar  =  Bus; 


Figure  3:  Basic  Software  Architecture  Representation  Example. 

3.4  Representation 

Figure  4  shows  our  representation  for  configurable  software  architecture  as  an  extension  to  the 
basic  architectural  skeleton  that  we  introduced  in  Figure  2.  Below,  we  discuss  one  by  one  how  this 
extended  representation  addresses  the  problems  of  capturing  evolution,  optionality,  and  variability. 

3.4.1  Evolution 

Our  first  step  towards  building  a  representation  for  configurable  software  architecture  is  the 
addition  of  a  revision  number  to  each  of  the  exemplars.  To  capture  the  evolution  of  an  exemplar, 
the  revision  numbers  of  subsequent  editions  of  the  exemplar  are  related  to  each  other  in  a  version 
tree.  This  scheme  follows  the  practice  of  many  standard  configuration  management  solutions. 
However,  our  solution  deviates  in  two  important  ways.  First  of  all,  we  note  the  intentional  use  of 
the  term  revision  number  as  opposed  to  the  more  conventional  term  version  number.  In  traditional 
CM  systems,  the  version  tree  captured  both  evolution  and  variability.  In  our  representation,  we 
separate  these  two  and  only  support  evolution  through  the  version  tree.  In  essence,  we  expect  the 
version  tree  to  evolve  linearly.  To  indicate  this  expectation,  we  use  the  more  specific  term  revision 
number.  Of  course,  branches  are  still  allowed  in  the  version  tree,  but  only  to  represent  parallel 
work.  We  expect  such  parallel  work  to  be  temporarily  and  eventually  be  merged  in  with  the  main 
line  of  development. 

The  second  deviation  also  concerns  branches.  A  different  kind  of  branch  from  the  branch 
for  parallel  work  is  the  one  where  a  separate  line  of  development  starts  (e.g.,  a  new  baseline). 
Traditionally,  such  a  branch  is  labeled  in  the  version  tree  as  a  special  branch  by  using  some  kind 
of  attribute  mechanism.  In  our  representation,  we  separate  out  this  kind  of  branching  and  adopt 
the  solution  used  in  Perforce,  namely  inter-file  branching  [26].  When  a  new  baseline  is  created  for 
an  exemplar,  the  exemplar  is  copied  to  a  new  name  space  with  a  new  version  tree.  Thus,  the  new 
baseline  can  evolve  separately  from  the  old  baseline.  Of  course,  we  track  the  ascendant /descendant 
relationship  among  the  old  and  new  baselines  in  our  representation. 

Once  exemplars  evolve,  the  question  arises  as  to  how  particular  revisions  of  instances  are  se¬ 
lected  during  hierarchical  composition.  In  our  representation  we  have  chosen  a  rather  simple 
scheme:  instances  are  instances  of  particular  revisions  of  exemplars,  and  exemplars  are  hierarchi¬ 
cally  constructed  based  on  these  instances.  This  implies  that  exemplars  are  constructed  in  terms 
of  specific  revisions.  Although  more  complicated  schemes  based  on  advanced  selection  rules  are 
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Figure  4:  Configurable  Software  Architecture  Representation. 


certainly  a  possibility,  for  simplicity  we  have  chosen  to  not  incorporate  such  a  scheme  yet. 

Figure  5  illustrates  how  the  addition  of  evolution  influences  our  example.  We  first  note  that 
each  exemplar  is  versioned  and  identified  by  a  name  and  a  revision  number.  In  the  example,  we  are 
defining  revision  3  of  the  exemplar  GlobalOptimization.  Additionally,  we  note  that  each  instance 
is  defined  in  terms  of  a  specific  revision  of  its  exemplar.  For  example,  the  interface  instance  result 
is  based  on  the  exemplar  Point  revision  2.  The  last  observation  we  make  is  that  the  exemplar 
GlobalOptimization  has  a  descendant,  namely  ComplexGlobal Optimization  revision  1.  The 
descendant  indicates  the  beginning  of  a  separate  baseline,  that  is  branched  off  from  revision  3  of 
the  exemplar  GlobalOptimization. 

3.4.2  Optionality 

Optionality  is  an  underdeveloped  area  in  both  the  disciplines  of  software  architecture  and  config¬ 
uration  management.  The  sole  architecture  description  language  that  explicitly  supports  optionality 
is  Koala  [37].  Even  so,  only  the  optionality  of  interfaces  can  be  specified,  and  the  optional  primitive 
does  not  extend  to  components  or  connections.  With  respect  to  configuration  management,  none 


8 


InterfaceExemplar 
name  =  Point; 
revision  =  2; 
representation  =  { 
integer  x; 

} 

ComponentExemplar 

name  =  GlobalOptimization; 
revision  =  3; 
interfaces  =  result; 
components  =  opt,  eval; 
connections  =  busl,  pipel; 

ascendant  =  (none); 
descendant  = 

ComplexGlobalOptimization(  1 ) ; 


Interface 

name  =  result 
direction  =  in 

interfaceExemplar  =  Point  (2); 


ComponentExemplar 

name  =  ComplexGlobalOptimization; 

revision  =  1; 

interfaces  =  result; 

components  =  complexOpt,  eval; 

connections  =  fastBusl,  pipel; 

ascendant  =  GlobalOptimization(3); 
descendant  =  (none); 


Figure  5:  Architectural  Evolution  Example. 


of  the  system  modeling  languages  developed  to  date  explicitly  supports  optionality.  The  attribute 
mechanism  used  for  selection  purposes  can  be  leveraged  to  provide  a  rudimentary  way  of  supporting 
optionality,  but  the  optionality  aspects  of  the  system  model  are  relatively  hidden  this  way. 

In  our  representation,  we  explicitly  model  optionality  through  the  use  of  properties.  As  shown 
in  Figure  4,  each  interface,  component,  or  connection  instance  that  is  used  in  the  hierarchical 
construction  of  an  exemplar  can  be  guarded  with  an  optional  property  name/value  pair.  The 
property  name  specifies  the  name  of  the  property  that  the  inclusion  of  an  instance  depends  on, 
whereas  the  property  value  specifies  the  exact  value  that  the  property  should  have  to  actually 
include  the  instance  in  the  specification. 

To  determine  which  options  are  included  in  a  (partial)  system,  an  exemplar  sets  the  values  for 
the  properties  that  it  desires  to  use.  These  values  are  propagated  down  the  hierarchical  chain  of 
inclusion  to  properly  select  all  parts  of  the  system.  Currently,  an  exact  match  is  required  between 
the  optional  property  value  and  the  selected  value  to  include  the  optional  interface,  component, 
or  connection.  Of  course,  more  powerful  logic-based  schemes  can  be  devised,  but  we  have  not 
implemented  any  of  these  yet. 

Figure  6  demonstrates  the  use  of  optionality  in  our  representation.  We  have  extended  the 
example  of  Figure  5  with  an  optional  part  that  gathers  statistics.  A  component  stat  and  a 
connection  bus2  are  now  included  in  the  exemplar  GlobalOptimization,  but  it  should  be  noted 
that  both  are  guarded  by  a  property  called  statistics  that  has  to  have  the  value  true  for  either 
to  be  included.  Inside  the  definition  of  the  exemplar  Optimizer,  the  interface  stat  is  optional  as 
well,  depending  on  the  same  property  statistics  as  the  other  optional  parts  of  the  architecture. 
Whether  or  not  the  optional  parts  are  included  in  the  architecture  depends  on  the  value  of  the 
property  statistics.  In  this  case,  the  exemplar  GlobalOptimization  defines  the  property  to  be 
true,  which  results  in  the  inclusion  of  all  optional  parts. 
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ComponentExemplar 

name  =  GlobalOptimization; 
revision  =  3; 
interfaces  =  result; 
components  =  opt,  eval, 
stat  (statistics  ==  true); 
connections  =  busl,  pipel, 
bus2(statistics  ==  true); 
properties  =  { 
statistics  =  true; 

} 


ComponentExemplar 
name  =  Optimizer; 
revision  =  1; 

interfaces  =  stat  (statistics  ==  true); 
components  =  (none); 
connections  =  (none); 


Figure  6:  Architectural  Optionality  Example. 


3.4.3  Variability 

Rather  than  following  an  implicit  approach  in  which  variability  is  locally  defined  inside  a  com¬ 
ponent  (such  as,  for  example,  required  in  PCL  [32]),  our  representation  derives  from  the  approach 
taken  by  Adele  [9]  and  explicitly  defines  variability  as  a  separate  entity  inside  a  specification.  In 
particular,  we  define  two  new  types  of  exemplars:  a  variant  component  exemplar  and  a  variant 
connection  exemplar.  Given  that,  analogous  to  the  way  a  connection  exemplar  is  syntactically 
equivalent  to  a  component  exemplar,  the  syntax  of  a  variant  connection  exemplar  is  identical  to 
the  syntax  of  a  variant  component  exemplar,  we  only  discuss  the  specifics  of  a  variant  component 
exemplar  here. 

Our  decision  to  define  a  variant  component  exemplar  as  a  separate  entity  in  our  representation 
stems  from  the  following  three  requirements. 

•  The  representation  must  support  the  ability  to  define  independently  developed  component 
exemplars  as  variants  of  each  other. 

•  The  representation  must  support  the  ability  to  evolve  the  definition  of  a  variant  just  like  any 
other  regular  component  exemplar  or  interface  exemplar  can  evolve. 

•  The  representation  must  be  able  to  define  a  variant  once  and  use  its  definition  many  times. 

To  satisfy  these  requirements,  a  variant  component  exemplar  is  a  separate  entity  that  can  evolve 
and  contain  optional  interfaces  just  like  a  regular  component  exemplar.  However,  its  hierarchical 
containment  is  defined  rather  differently.  As  opposed  to  being  hierarchically  constructed  in  terms 
of  components  and  connections,  a  variant  component  exemplar  is  defined  by  a  number  of  com¬ 
ponents  that  each  have  the  same  interfaces  as  the  variant  component  exemplar.  In  addition,  the 
variant  component  exemplar  specifies  a  property  name  for  which  each  contained  component  has 
an  associated  property  value.  Based  on  the  value  of  the  property  as  defined  in  a  “higher-level” 
component  exemplar,  the  variant  component  selects  one  of  the  contained  components  as  the  one 
that  is  selected  to  be  included  in  the  system. 

To  account  for  the  existence  of  both  component  exemplars  and  variant  component  exemplars,  a 
component  instance  is  now  either  an  instance  of  a  component  exemplar  or  an  instance  of  a  variant 
component  exemplar.  Because  instances,  when  used  in  hierarchical  composition,  are  only  connected 
through  interfaces,  and  both  regular  and  variant  component  exemplars  are  defined  in  terms  of  their 
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ComponentExemplar 

name  =  GlobalOptimization; 
revision  =  3; 
interfaces  =  result; 
components  =  opt,  eval, 
stat  (statistics  ==  true); 
connections  =  busl,  pipel, 
bus2(statistics  ==  true); 
properties  =  { 
statistics  =  true; 
speed  =  fast; 

} 


VariantComponentExemplar 
name  =  Optimizer; 
revision  =  1; 

interfaces  =  stat  (statistics  ==  true); 
optionalProperty  =  speed; 
components  =  slowOpt(slow), 
fastOpt(fast); 


Figure  7:  Architectural  Variability  Example. 


interfaces,  component  instances  can  be  used  in  the  same  way  regardless  of  whether  they  represent 
a  regular  or  a  variant  component  exemplar. 

To  illustrate  variability  in  our  example,  we  take  a  look  at  the  exemplar  Optimizer.  Figure  7 
illustrates  how  this  exemplar  is  defined  in  terms  of  two  variant  components:  an  instance  of  the 
exemplar  Fast  Optimizer,  called  fastOpt  and  an  instance  of  the  exemplar  SlowOptimizer,  called 
slowOpt.  Selection  of  one  of  the  two  instances  depends  on  the  property  speed,  which  can  have  the 
values  slow  and  fast.  In  this  particular  case,  the  exemplar  GlobalOptimization  sets  the  value 
of  the  property  to  fast,  which  through  hierarchical  propagation  causes  the  fastOpt  component 
instance  to  be  included  in  the  architecture. 

4  Environment 

Maintaining  a  configurable  software  architecture  by  writing  specifications  by  hand  is,  of  course, 
a  difficult  and  error- prone  task.  Therefore,  we  have  constructed  a  simple  environment,  called 
Menage,  that  supports  the  graphical  construction  of  configurable  software  architectures.  Shown  in 
Figure  8,  the  environment  is  divided  into  three  separate  areas.  The  first  area,  displayed  on  the 
left,  contains  lists  of  available  component,  connection,  and  interface  exemplars.  These  exemplars 
have  been  previously  created,  and  can  be  used  in  the  hierarchical  construction  of  new  exemplars. 
The  largest  available  area  of  the  environment  is  used  exactly  for  this  purpose;  i.e.,  it  allows  new 
exemplars  to  be  specified.  These  exemplars  can  be  completely  new  exemplars,  or  exemplars  that  are 
new  revisions  of  existing  ones.  As  an  example,  the  Figure  displays  the  specification  of  revision  3 
of  the  component  exemplar  GlobalOptimization,  which  is  constructed  out  of  instances  of  an 
Optimizer,  a  FunctionEvalation,  and  a  Statistics  exemplar.  The  interfaces  of  the  components 
are  connected  via  connections  of  two  kinds:  buses  and  pipes.  It  should  be  noted  that  the  component 
stat,  the  connection  bus2,  and  the  interface  stats  on  the  component  opt  are  highlighted  with 
a  white  border  to  indicate  their  optionality.  Depending  on  the  value  of  the  optional  property 
statistics,  these  instances  are  included  in  the  architecture  or  not. 

The  third  area  of  the  environment  shows  the  evolution  of  the  exemplar  that  is  currently  be¬ 
ing  defined.  In  the  version  tree  displayed  at  the  top  of  the  figure,  we  see  that  the  exemplar  has 
evolved  through  three  generations.  New  revisions  are  created  via  a  traditional  check-out /check¬ 
in  mechanism  that  is  supported  by  the  environment.  Change  comments  are  associated  with 
each  check-in,  and  a  history  of  changes  can  be  obtained.  The  special  mark  on  revision  3  indi¬ 
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Figure  8:  Menage  Configurable  Software  Architecture  Environment. 


cates  that  this  revision  serves  as  a  branching  point  for  a  new  baseline  .  In  this  case,  the  ex¬ 
emplar  ComplexGlobalOptimization  evolved  out  of  the  (immutable)  revision  3  of  the  exemplar 
GlobalOptimization. 

Figure  9  shows  how  the  environment  supports  variability.  A  variant  component  exemplar, 
Optimizer,  is  being  defined  in  terms  of  instances  of  two  other  component  exemplars  that  each  have 
the  exact  same  interfaces  as  the  Optimizer  exemplar.  The  variant  property  is  speed,  and  one  of  the 
contained  component  instances,  slowOpt,  is  a  slow  optimizer  (as  indicated  by  the  variant  property 
value  slow  that  is  associated  with  the  component),  whereas  the  other  instance,  fast  Opt,  is  a  fast 
optimizer  (as  indicated  by  the  variant  property  value  fast  that  is  associated  with  the  component). 
Depending  on  the  value  of  the  property  speed  as  given  to  it  by  a  higher-level  exemplar  in  the 
architecture,  the  Optimizer  selects  either  the  slowOpt  or  the  fastOpt  component  to  be  included 
in  the  architecture. 

Of  course,  configurable  software  architectures  that  are  specified  in  the  environment  need  to  be 
verified  for  correctness.  Two  types  of  verification  processes  are  supported.  The  first  is  incorporated 
in  the  environment  itself  and  is  able  to  verify  the  correct  use  of  properties  and  variants;  conflict¬ 
ing  properties  in  different  parts  of  the  architecture  can  be  detected,  undefined  properties  can  be 
uncovered,  and  improper  variant  specifications  can  be  discovered.  The  second  verification  process 
is  based  on  a  reduction  to  a  specification  in  a  “native”  ADL.  A  configurable  software  architecture 
in  our  specification  is  reduced  to  a  specification  in  a  particular  ADL  (such  as,  for  example,  C2  or 
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Figure  9:  Specifying  Variability  in  Menage. 

Darwin)  and  the  verifier  of  the  particular  ADL  is  invoked  to  determine  whether  the  specification 
is  sound. 

5  Opportunities 

As  already  stated  in  the  introduction,  the  development  of  our  representation  is  preliminary  in 
terms  of  experience.  We  have  not  been  able  to  put  the  representation  in  actual  use  just  yet,  but 
we  do  have  identified  some  of  the  opportunities  that  we  believe  can  benefit  from  the  availability  of 
a  representation  for  configurable  software  architecture.  In  this  section,  we  briefly  discuss  three  of 
those  opportunities. 

5.1  Active  Patches 

One  of  the  activities  that  is  currently  supported  by  some  of  the  architectural  approaches  is 
architectural  reconfigurability.  In  C2,  for  example,  wizard  scripts  contain  algorithms  to  update  the 
architecture  of  a  system  at  run  time  [22],  Until  now,  these  wizard  scripts  had  to  be  created  by  hand; 
a  designer  has  to  study  the  differences  between  the  actual  architecture  and  the  architecture  that 
is  desired.  Obviously,  this  can  be  a  rather  laborious  and  potentially  error-prone  process.  Given  a 
representation  for  configurable  software  architecture,  the  differences  between  the  actual  and  desired 
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architecture  can  be  calculated  using  a  difference  algorithm.  It  should  be  noted  that  the  result  of 
the  difference  algorithm  can  be  rather  distinct  from  the  classical  output  of  a  difference  between 
two  source  files.  Whereas  in  the  latter  case  the  output  is  a  simple  listing  of  textual  differences, 
the  structural  nature  of  an  architecture  facilitates  a  semantic  interpretation  of  the  differences.  In 
particular,  it  seems  to  be  possible  to  generate  active  patches  that,  rather  than  being  a  listing  of 
differences,  are  much  like  a  wizard  script;  the  active  patch  contains  an  algorithm,  that,  if  applied 
to  a  particular  architecture,  transforms  that  architecture  into  a  different  architecture  [35]. 

5.2  Dynamic,  Multi- Version  Systems 

Highly  reliable  and  fault-tolerant  applications  are  often  constructed  as  self-configuring,  multi¬ 
version  systems  in  which  critical  functionality  is  implemented  in  alternative  ways  in  different  com¬ 
ponents.  In  these  applications,  an  arbitrator  typically  determines  which  component  are  active  and 
which  results  are  used.  Depending  on  the  quality  of  the  results  from  the  various  components,  the 
arbitrator  has  the  ability  to  reconfigure  the  application  to  include  new  components,  remove  com¬ 
ponents,  activate  or  deactivate  components,  and  sometimes  even  to  rewire  how  the  components 
are  connected.  Obviously,  a  strong  relationship  exists  between  these  types  of  applications  and  our 
representation.  In  particular,  the  variant  relationship  that  is  captured  by  our  representation,  com¬ 
bined  with  our  property-based  optionality  mechanism,  could  be  used  to  support  the  definition  and 
reconfiguration  of  these  types  of  applications. 

An  alternative  way  of  improving  the  reliability  of  an  application  is  described  in  [8] .  Rather  than 
using  variants,  the  approach  is  based  on  the  incremental  inclusion  of  multiple  revisions  of  the  same 
component.  Once  again,  an  arbitrator  is  used  to  determine  which  results  from  which  component 
revisions  are  used  in  the  application.  Of  course,  our  representation  could  serve  the  same  role  in 
this  scenario  as  it  does  in  the  above:  because  the  evolution  of  a  component  is  precisely  captured, 
the  representation  could  be  used  to  support  the  definition,  evolution,  and  reconfiguration  of  these 
types  of  multi-version  applications. 

5.3  Architectural  Erosion 

One  of  the  main  problems  identified  in  the  software  architecture  literature  is  architectural 
erosion:  once  the  conceptual  architecture  of  a  system  has  been  created,  it  becomes  out  of  date  with 
respect  to  the  actual  architecture  that  is  embedded  in  the  implementation  of  the  system  [24],  To 
remedy  this  situation,  it  is  often  attempted  to  organize  the  structure  of  the  source  code  of  a  system 
along  its  architectural  components.  However,  this  turns  out  to  be  a  rather  difficult  exercise  that 
is  not  very  well  supported  by  the  current  configuration  management  tools;  these  tools  are  geared 
towards  managing  the  structure  of  the  source  code,  not  the  structure  of  the  system  itself. 

Our  representation  offers  a  unique  opportunity  to  approach  the  problem  of  architectural  erosion. 
In  particular,  the  representation  not  only  captures  the  structure  of  a  system,  but  also  its  evolution 
over  time.  This  complements  the  functionality  of  traditional  configuration  management  systems 
which  only  capture  the  structure  and  evolution  of  the  system  implementation.  We  believe  it  is  pos¬ 
sible  to  build  a  configuration  management  system  that  utilities  our  representation  for  configurable 
software  architecture  to  support  its  activities.  In  particular,  we  believe  it  is  possible  to  organize 
these  activities  in  terms  of  the  architecture  of  the  system  that  is  being  managed.  This  makes  the 
architecture  a  first-class  citizen  in  the  configuration  management  system,  thereby  allowing  it  to  be 
managed  and  evolved  at  the  same  time  as  the  implementation.  This,  in  turn,  allows  the  architecture 
and  implementation  to  be  kept  in  sync  over  time. 
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6  Related  Work 


Perhaps  most  surprising  is  the  limited  amount  of  attention  that  has  been  paid  by  the  discipline 
of  software  architecture  to  properly  capturing  configurability.  Despite  all  the  work  in  architectural 
reconfigurability  that  could  obviously  benefit  from  the  availability  of  such  a  representation  (e.g.,  [1, 
18,  22,  27]),  Unicon  [28]  and  Koala  [37]  are  the  only  two  ADLs  that  have  explicitly  addressed  part  of 
the  problem.  Unicon  incorporates  a  mechanism  to  specify  variant  implementations  of  components, 
whereas  Koala  allows  the  specification  of  components  that  have  optional  interfaces.  However,  in 
both  cases  only  a  small  part  of  the  larger  problem  of  capturing  configurability  is  addressed,  and 
our  work  subsumes  either  solution. 

One  additional  architectural  effort  to  support  evolution  should  be  mentioned.  DRADEL  [20] 
is  an  environment  and  language  that  supports  evolution  through  subtyping.  Although  different  in 
nature  from  our  solution,  it  does  provide  an  alternative  mechanism  to  capture  evolution.  However, 
neither  optionality  nor  variability  is  addressed  by  DRADEL. 

From  a  configuration  management  perspective,  much  work  is  (of  course)  related  to  our  efforts 
of  capturing  architectural  configurability.  As  previously  described,  we  have  borrowed  and  adapted 
a  variety  of  concepts  that  have  been  established  in  the  discipline  for  quite  some  time  now.  Still, 
our  representation  differs  considerably  from  most  system  modeling  languages  developed  to  date. 
Perhaps  the  one  system  modeling  language  that  is  closest  to  ours  in  terms  of  expressive  capabilities 
is  Adele  [9].  However,  compared  to  its  capabilities,  our  representation  supports  optionality,  allows 
the  definition  of  variability  in  terms  of  multiple  interfaces  as  opposed  to  just  one,  facilitates  the 
evolution  of  variable  components  just  like  regular  components,  and  incorporates  the  notion  of 
connections. 

7  Conclusions 

In  this  paper,  we  have  discussed  a  rather  different  topic:  the  application  of  configuration  man¬ 
agement  techniques  to  software  architecture.  We  have  developed  the  abstraction  of  configurable 
software  architecture  and  created  a  representation  that  captures  the  variability,  optionality,  and 
evolution  of  architectures.  In  addition,  we  have  described  an  environment  that  can  be  used  to 
graphically  specify  configurable  software  architectures.  Although  the  research  is  still  in  its  pre¬ 
liminary  stages,  we  believe  the  work  presented  here  does  make  a  number  of  contributions.  The 
most  important  contribution  is  a  precise  representation  for  capturing  configurability  as  an  inte¬ 
gral  part  of  software  architecture.  Not  only  has  such  a  representation  been  lacking  until  now,  but 
our  representation  explicitly  recognizes  the  concepts  of  variability,  optionality,  and  evolution  as 
equally  important  entities  in  the  representation.  A  secondary  contribution  is  the  fact  that  we  have 
successfully  applied  and  adapted  configuration  management  techniques  to  operate  outside  of  the 
traditional  domain  of  managing  source  code. 

Much  work  still  remains  to  be  done.  Our  immediate  concerns  are  to  put  our  representation 
in  actual  use.  In  particular,  our  plans  are  to  build  a  configuration  management  and  software 
deployment  system  that  are  explicitly  based  on  configurable  software  architecture. 
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